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BACKGROUND OF THE INVENTION 
The invention relates generally to stored value fund transactions, and more 
particularly relates to transferring money between parties with a network-accessible 
stored value fund. 

One party may wish to transfer money to herself, a counter party, or vice 
versa, for any of a variety of reasons. Frequently, a payor party owes a debt to a payee 
party. The debt may be an informal IOU or a more formal transaction. Other times, the 
payor may wish to give the money to the payee as a gift. For example, the payee may 
have sold an auction item to the payor. 

Until recently, payors typically complete such payments via cash, check or 
money order because the payee does not have the ability to receive money electronically. 
Electronic payment methods exist, such as credit cards and bank account debits through 
electronic fund transactions, however, the payor may not have access to these methods for 
whatever reason. For example, these electronic payment methods may require purchasing 
hardware and/or software to support accepting payment. Configuration, maintenance, 
and training for these electronic payment methods are costly and time consuming. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The present invention is described in conjunction with the appended 

figures: 

FIG. 1 is a block diagram of an embodiment of an online money transfer 
system that is interfaced to a payor and payee; 

FIG. 2 is a block diagram of another embodiment of an online money 
transfer system; 

FIG. 3 is a block diagram of an embodiment of a payment enabler; 
FIG. 4 is a block diagram of an embodiment of an agent location that 
includes an agent interface and kiosk interface; 
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FIG. 5 A is a flow diagram of an embodiment of a process for transferring 
money to a number of payees; 

FIG. 5B is a flow diagram of another embodiment of the process for 
transferring money to a number of payees that automates entry of transfer information; 
5 FIG. 6A is a flow diagram of an embodiment of a process for transferring 

money that could include the payee receiving a negotiable instrument; 

FIG. 6B is a flow diagram of another embodiment of the process for 
transferring money with the negotiable instrument where the payor uses an agent location; 

FIG. 7 is a flow diagram of an embodiment of a process for configuring a 
10 user with an account for the online money transfer system; 

FIG. 8 is a flow diagram of an embodiment of a process for transferring 
money from the payor to the payee; 

FIGS. 9 A and 9B are a flow diagram of an embodiment of a process for 
moving money out of a stored value fund for a user; 
1 5 FIG. 10 is a flow diagram of an embodiment of a process for automating 

future transfers that uses the online money transfer system; and 

FIGS. 1 1A and 1 IB are a flow diagram of an embodiment of a process for 
subscribing to automated transfers. 

In the appended figures, similar components and/or features may have the 
20 same reference label. Further, various components of the same type may be distinguished 
by following the reference label by a dash and a second label that distinguishes among the 
similar components. If only the first reference label is used in the specification, the 
description is applicable to any one of the similar components having the same first 
reference label irrespective of the second reference label. 

25 DESCRIPTION OF THE SPECIFIC EMBODIMENTS 

The ensuing description provides preferred exemplary embodiment(s) 
only, and is not intended to limit the scope, applicability or configuration of the invention. 
Rather, the ensuing description of the preferred exemplary embodiment(s) will provide 
those skilled in the art with an enabling description for implementing a preferred 
30 exemplary embodiment of the invention. It being understood that various changes may 
be made in the function and arrangement of elements without departing from the spirit 
and scope of the invention as set forth in the appended claims. 
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The present invention facilitates online money transfers between a payor 
and a number of payees. By accessing an online payment enabler through the Internet or 
other wide area network, users can transfer money. The money is paid in or out through 
money handlers such as credit/debit cards, banks, promotion programs, and agent 
locations. The ability for a payor to transfer money to a large number of payees in a 
single transaction, in this embodiment, greatly simplifies payment distribution. 

Money is transferred between users of the online money transfer system. 
Money is a credit amount stored as a database entry corresponding to the user. The 
database entry corresponds to a stored value fund for that user that can be supplemented 
by transferring-in credit or reduced by transferring-out credit. The money or credit is 
transferred between users by updating the database entries for the users involved in the 
transfer. Money could be in any currency or be anything of monetary value, for example, 
airline mileage, promotional program points, gift certificate credit, commodities such as 
gold, etc. 

Referring initially to FIG. 1, a block diagram of an embodiment of an 
online money transfer system 100 is shown interfaced to a payor 110 and payee 130 by 
way of the Internet 150 or a plain old phone system (POTS) 155. Although this 
embodiment shows users 100, 130 interfaced through the Internet 150 or the POTS 155, 
any other wide area network technology could be used. This embodiment demonstrates 
some interfaces to the payment enabler 170, but other interface arrangements are possible. 
The money transfer system 100 includes a payment enabler 170, a number of user 
interfaces 180 and a number of money handlers 160. 

The payment enabler 170 controls the flow of credits throughout the 
system 100. Credit is received by the payment enabler 170 from the money handlers 160 
where a payor or sender 110 transfers the credit to a payee or receiver 130. The credit is 
transferred by the payee 130 to a selected money handler 160. Presumably, the payee 130 
can retrieve and use the credit after it is transferred to the money handler 160. 

Users 110, 130 and/or agents interact with the payment enabler 170 
through user interfaces 180. These interfaces 180 are designed to couple different front 
ends to the payment enabler 170. In the depicted embodiment, there are three types of 
user interfaces 180. One interface supports Internet 150 connections to the payment 
enabler 170. Any number of devices could communicate by way of the Internet 150, but 
this embodiment uses computers 120 associated with the payor 1 10 and payee 130 to 
interact with the payment enabler 1 70. Another user interface 1 80 allows communication 



with telephones 140 over the POTS network 140. Yet another interface allows an agent 
location 125 to communicate with the payment enabler. The agent could add and remove 
money from the payment enabler 170 under the direction of a payor 120 or payee 130. 

The money handlers 160 are typically organizations that are used to pay 
5 for items or to store money, but often are difficult for the payor or payee 1 10, 130 to use 
when making payments. Examples of money handlers 160 include credit/debit cards, 
banks, promotion programs, and agent locations 125. In this embodiment, the agent 
location 125 serves as an interface to the payment enabler 170 as well as a money handler 
160. Handlers 160 have established mechanisms for moving money that payors 110 and 
10 payees 130 are accustomed to using, such as, paying for items with a credit card and 
withdrawing money from a bank. However, payors 1 10 and payees 130 may have no 
y. way to accept credit cards or wire transfers. 

w With reference to FIG. 2, a block diagram of another embodiment of an 

J; online money transfer system 200 is shown without the payors 1 10 or payees 130. In this 

**j 15 embodiment, five handlers 160 and five user interfaces 180 are shown. Other 

y embodiments could have more or less handlers 160 and interfaces 180. Each of the 

^ j handlers 160 allows a user to add and/or remove money from the payment enabler 170. 

.y, Normally, the payee 130 can choose the handler 160, but in some circumstances, the 

payor 1 1 0 can choose the handler 1 60. The user interfaces 1 80 allow interaction with the 
gn 20 payment enabler 1 70 to transfer funds. 

W The promotion handler 160-1 allows adding and removing money in a 

form other than legal tender or negotiable instrument. Examples include airline mileage 
programs and gift certificate programs. For example, a user could use money in their 
stored value fund to purchase airline miles with an airline mileage handler 160-1. A 

25 conversion rate would be applied to convert the money to mileage credit. The promotion 
handler 160-1 may need special information from the payment enabler 170, such as the 
user's promotion account number or type of gift certificate. 

The credit and debit card handlers 160-2, 160-3 behave largely the same. 
Both can be used to add money into the payment enabler 170. In other embodiments, 

30 these handlers 160-2, 160-3 can also be used to remove money from the payment enabler 
170 also. To use these handlers 160-2, 160-3, the payment enabler 170 stores the 
information for receiving money from credit or debit cards in the conventional way, such 
as the account number, expiration date, name, and/or PIN. 
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The bank handler 160-4 allows electronic funds transfer (EFT) of money 
to a bank account of the user. The user enters the account number and routing 
information into the payment enabler 170 with a user interface 180 to facilitate adding 
and removing of money from the payment enabler with this handler 160-4. In one 
embodiment, an automated teller machine (ATM) could incorporate the bank handler 
160-4 along with an ATM interface 180-1 to allow adding and removing funds along with 
interfacing with the payment enabler 170. Another embodiment uses a bank handler 160- 

4 branch location as an agent interface 180-4 for interacting with the payment enabler 
170. 

The agent handler 160-5 typically corresponds to an agent location 125 
that may wire money, print money orders and/or cash checks. Money may be sent to the 
agent handler 160-5, whereafter the user receives cash or a negotiable instrument for that 
money. Money can be added to the system 100 by the agent handler also. For example, 
the user may give cash to the agent who enters a credit into the payment enabler. The 
user could further specify to the agent a payee to receive the money. An agent interface 
180-4 at the agent location 125 is used by the agent to indicate to the payment enabler 
1 70 that the money has been received from or by the user. Through an agent handler 160- 

5 a user could use the online money transfer system 100 without any knowledge of 
computers or any debit/credit card or bank account. 

As briefly discussed above, the ATM interface 180-1 allows interaction 
with the payment enabler 170. The user may or may not have an affiliation with the 
ATM that is used to interface with the payment enabler 170. Under this circumstance, the 
owner of the ATM may charge the user a fee for this service. The user can receive cash 
or deposit cash if the ATM is coupled to a bank handler 160-4. In any event, the ATM 
interface 180-1 can be used to interface with the payment enabler 170 in the same way a 
user may interact through a web browser with the payment enabler 170. If the ATM has a 
magnetic stripe or smart card reader, this could be used by to avoid entering credit or 
debit card information manually for the payment enabler 170. 

A kiosk interface 180-2 allows a user to interact with the payment enabler, 
but typically does not allow adding or removing cash. The kiosk interface 1 80-2 may be 
a browser terminal available for general use. Some embodiments may include a check or 
money order printer for removing money from the system 100. The kiosk interface 180-2 
could be in an agent location 125 and linked to the other systems in the agent location 
125. 



An Internet interface 1 80-3 is typically implemented through a web 
browser. The browser downloads web pages from the payment enabler 170. The Internet 
interface could be hosted by the computer 120 of the user. Some embodiments could host 
the Internet interface on a portable device such as a wireless phone or personal digital 
assistant (PDA). The Internet interface 1 80-3 may also be used by the ATM, kiosk and 
agent interfaces 180-1, 180-2, 180-4 in whole or in part. The Internet interface 180-3 
uses encryption for the link to the payment enabler 170 in some embodiments. 

The agent interface 180-4 allows for specialized interaction by an agent at 
the agent location 125. Agents typically have special training and offer enhanced services 
over most interfaces 180 and handlers 160. The agent can move money between payors 
1 10 and payees 130 at the direction of the user. Also, the agent can pay-in and pay-out 
money from the transfer system 100. The agent interface 180-4 allows an agent to act on 
behalf of the user when manipulating the user's account. For security, the user's 
password or PIN may be entered during this manipulation. 

Interaction with the payment enabler 170 may also be performed over a 
telephone 140 interfaced to the POTS 155. The phone interface 180-5 provides voice 
prompts and recognizes the user's touch-tone or speech recognized input. Enhanced 
interaction with the phone interface 180-5 could be provided with wireless phones having 
wireless access protocol (WAP) or browser graphical user interfaces (GUIs). 

Referring next to FIG. 3, a block diagram of an embodiment of a payment 
enabler 170 is shown. The transfer of money between handlers 160, stored value funds 
and users 1 10, 130 is controlled by the payment enabler 170. The payment enabler 170 
may be implemented on one or more computers in one or more locations where the 
various computers communicate over a network. Included in the payment enabler 170 are 
a payment controller 304, handler interfaces 308, a billing function 3 12, a messaging 
function 316, an enabler interface 320, a user database 324, a payment conversion 
function 328, and an exchange rate database 332. 

The payment controller 304 manages operation of the payment enabler 
170. The handlers 160 and interfaces 180 along with user information and money 
conversion tasks are all choreographed by the payment controller 304. The payment 
controller 304 is interconnected to the other portions of the payment enabler 170 by one 
or more networks. 

The payment conversion function 328 allows converting between disparate 
forms of money as it is transferred through the system 100. An exchange rate database 



332 holds conversion factors that allow determining the proper weight to give one form of 
money. In a simple example, the payment conversion function 328 may convert money 
in U.S. dollars to money in European Union Euros. In another example, a user may 
convert money into airline miles of eight miles for every dollar for a promotion handler 
160-1. The exchange rate database 332 is updated with conversion rates as often as 
practical using conventional methods. The conversion rate may accommodate a 
percentage service fee for the exchange or a flat fee could be charged. 

A billing function 312 monitors and charges for the services of the 
payment enabler 170. There may be charges when transferring money, converting 
money, printing and mailing negotiable instruments, using kiosks, ATMs or agent 
locations, etc. These charges are normally deducted from a transfer, but other 
embodiments could charge monthly fees. The different types of handlers 160 may have 
different fees associated with them. For example, a credit card may have a three percent 
charge, but a bank transfer may only have a one percent charge. The payor and/or the 
payee can be charged to transfer money between themselves. The transfer in or out of the 
system 100 may incur a separate charge. The billing function 312 may issue invoices for 
some users. 

There are handler interfaces 308 to support the handlers 160. Each of 
these interfaces 308 may support a single handler 160 or a group of handlers. For 
example, a single interface may perform EFT to and from bank handlers 160. When 
money is sent to or received from a handler 160, the appropriate handler interface passes 
the money and transfer information to the payment controller. In some embodiments, the 
cost of the transfer to or from the handler is reported by the handler interface 308 such 
that the billing function can recover those costs. 

Information for the users of the system 100 is stored in the user database 
324. This information includes an address book of other users, money credit in the stored 
value fund, past money transfer information, account number, e-mail addresses, contact 
information, handler interface information, handler preference information, etc. The 
money credit is stored in a trust account for the benefit of the user according to the entry 
in the user database 324 corresponding to that user and interest may or may not be paid 
on that money credit. 

The enabler interface 320 is used by the various interfaces 180 to interact 
with the user. The enabler interface 320 produces the form web pages and informational 
web pages to allow the user to create and maintain their account, transfer money and learn 



to use the system 100. The appropriate user interface 180 formats and processes the 
enabler interface information according to the device used to interface with the payment 
enabler 170. For example, the Internet interface 180-3 takes the information from the 
enabler interface 320 and formats into hypertext mark-up language (HTML) appropriate 
for the computer 120 of the user. 

A messaging function 316 is used with some configurations to notify the 
user of certain events. Requests for money are sent by the messaging function 316 along 
with acknowledgment and billing messages. These messages could be accessed using a 
web browser, an e-mail program, an instant messaging program, a pager, a WAP enabled 
device, etc. In some embodiments, the messaging function 316 may issue printed bills for 
users. The messaging function 316 is also used to communicate with agent locations 125. 

With reference to FIG. 4, a block diagram of an embodiment of an agent 
location 125 is shown that includes an agent interface 180-4 and kiosk interface 180-2. 
Both interfaces 180-2, 180-4 are coupled to a wide area network 404 that is coupled to the 
payment enabler 170. 

The kiosk interface 180-2 is primarily intended for users to interact with, 
and the agent interface 180-4 is primarily intended for agents to interact with. In some 
embodiments, both interfaces 180-2, 180-4 are used to perform a transfer. For example, 
the agent may use the agent interface 180-4 to perform the transfer while the kiosk 
interface 180-2 is used to monitor the agent's actions and enter a password or PIN that is 
kept secret from the agent. The kiosk interface 180-2 may also be used to perform a 
complete transfer in circumstances where the user is trained to use the system 100, but 
does not utilize other interfaces 180 for whatever reason. 

The agent interface 180-4 and kiosk interface 180-2 can output a 
negotiable instrument with a printer 412. Examples of negotiable instruments include 
money orders, cashiers checks, tellers checks, certified checks, checks, gift certificates, 
coupons, etc. In some embodiments, each interface 180-2, 180-4 may have a separate 
printer. The printer 412 may also be used to print receipts and messages related to the 
transfer of money. 

Money can be added to or removed from the system 100 at the agent 
location 125 with money distribution devices 408, 416, 420. In the conventional manner, 
cash can be received by the cash register, credit or debit cards and be debited by the card 
terminal 408, and checks can be confirmed with a check validation terminal 420. Cash 
can be paid out from the cash register 416 or added to a credit or debit card by the card 
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terminal 408 in a conventional fashion. These money distribution devices 408, 416, 420 
all interface with the system 100 by way of the agent interface 180-4 such that pay-outs 
and pay-ins can be automatically recorded by the payment enabler 170. 

Referring next to FIG. 5 A, a flow diagram of an embodiment of a process 
5 500 for transferring money to a number of payees 1 30 is shown. In this embodiment, any 
number of payees 130 can receive money from a payor 1 10. The amount sent to each 
payee 130 can be the same or different. The target for the transfer can be a stored value 
fund or an external payout that goes strait to a handler 1 80 that prints a negotiable 
instrument for mailing or pick-up by the payee. 

10 The depicted portion of the process begins in step 504 where the payor 1 10 

logs in to the system 100 through the enabler interface 320 by way of the Internet 
interface 180-3. Under some circumstances, the payor 1 10 can avoid creating an account 
with the payment enabler 170 by acting as an external payor 1 10 in step 508. Avoiding 
account creation reduces the amount of information the payor 1 10 enters. Handler 

1 5 information for this external payor transfer is entered in step 516 and only used for this 
transfer and discarded when done. Some embodiments, may retain the handler 
information in case the payor 1 10 ever logs back into the system 100. If the payor 1 10 
does not remain external to the system 100, an account is opened in step 512 when there 
is no existing account. 

20 Regardless of whether the payor 1 10 is external to the system 100, the 

payor 110 enters the unique identifiers for the payees 130 in step 520. The unique 
identifiers in this embodiment are e-mail addresses of the payees 130, but could be any 
existing or new code that uniquely identifies the payee in other embodiments. Some 
embodiments may include an address book stored either locally or remotely with the 

25 payment enabler 170. The address book could include in a list the unique identifier for a 
single user or a group that includes the unique identifiers for the group of users. By 
selecting the group, all the included users become payees for the transfer. The group can 
further include the amount transferred last time to the users such that the amounts can be 
reused if they are the same for the new transfer. 

30 In step 524, it is determined if the payor 1 10 wishes to send an equal 

amount of money to each payee 130 of the money transfer. The payor 110 either enters 
the one amount for all payees 130 in step 528 or enters a unique amount for each payee 
130 in step 532. In any event, processing from steps 528 and 532 proceeds to step 536 
where the specified money amount is transferred into each payees 130 stored value fund. 
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At this point, the payment controller 304 communicates with the handler interface 308 to 
receive the money into the system 100. The allocated amount is recorded into the user 
database for each payee 130, but the aggregate money is stored in a trust account. 

In step 540, a determination is made as to whether the payout should be 
external to the system 100. Where an external payout is performed, the stored value fund 
used in step 536 can be a temporary fund that can be removed from the system after the 
payee 130 receives the money. In step 542, the payor 110 enters a delivery address for 
the payee 130. A message is sent to an agent location 125 with a negotiable instrument 
printer 412 that indicates a payee name, an amount and a delivery address. In step 544, 
the money order or other negotiable instrument is printed and sent to the address of the 
payee 130. Regular mail or courier services could be used to delivery the negotiable 
instrument. 

Where an external payout is not selected in step 540, processing continues 
to step 548. In that step, a message is sent to the payees notifying them of the available 
money. This message may include instructions for new users to create an account. If the 
user has an existing account, the message could indicate the total cash in the account 
and/or promotional information. In step 552, the payees 130 log into the enabler interface 
320. 

A determination is made in step 556 as to whether each payee 130 has an 
existing account. Where there is no account, one is opened by the payee 130 in step 512. 
Once the payee 130 has an account, processing proceeds to step 560 where the payee 130 
can move money out of her stored value fund. 

In this embodiment, the payor can choose an external payout in step 540 
such that the payee 130 need not have an account with the system 100. Other 
embodiments, could market a separate product where there is no option to send money to 
a permanent stored value fund of the payee 130 such that all payees 130 are external to 
the system and all payees 130 need not have an account with the system 100. In another 
embodiment, money could be transferred by the system 100 between the pay-in handler 
160 and the pay-out handler 160 without a need for the payor 1 10 or payee 130 having a 
stored value fund to temporarily store the money. The pay-out handler 160-5 could be an 
agent location 125 that prints and sends a negotiable instrument after receiving the money 
directly from the payor's pay-in handler 160 under the direction of the payment enabler 
170. 
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With reference to FIG. 5B, a flow diagram of another embodiment of the 
process 562 for transferring money to a number of payees 130 is shown that automates 
entry of transfer information. The transfer information includes for each payee: the payee 
name, unique identifier or e-mail address, money amount, and message body and title. A 
5 format such as extensible markup language (XML) or other conventional format can be 
used for this transfer inforamation. This embodiment allows automatically sending a file 
with transfer information or manually indicating the file. Other embodiments could allow 
cutting and pasting the transfer information. 

Where automatic sending of the transfer information is used, processing 
10 begins in step 566 where the transfer information is formulated by a payor computer 
system. For example, the payor computer may process holiday bonuses for employees. 
To pay the holiday bonuses, the payor computer could produce an XML file with the 
J? transfer information that is sent to the payment enabler 1 70 for distribution to the 

p employees. In step 570, a secure connection is made between the payor computer and the 

15 payment enabler 170 using, for example, a secure sockets layer (SSL) session. Once a 
fn secure link is established, the file with the transfer information is sent in step 574. 

f ! In some circumstances, the payor 110 may manually specify a file that 

s contains the transfer information. This alternative scenario begins in step 504 where the 

[T payor 1 10 logs into her account by way of the enabler interface 320. In step 582, the 

fsj 20 transfer information file is selected by the payor 110 specifying the URL or volume, path 

and file name. In step 584, the payor 1 10 begins the upload of the file using a secure 
y : connection such as SSL. A web page showing the transfer information is presented to the 

payor 1 10 in step 588 to allow verification of the information. Once the transfer 
information file is received, processing continues to step 536 in the same manner as that 
25 described in relation to FIG. 5 A above. 

Referring next FIG. 6A, a flow diagram of an embodiment of a process 
600 for transferring money that could include the payee 130 receiving a negotiable 
instrument is shown. In this embodiment, a single transfer occurs between a payor 110 
and a payee 130. For the external payout, the negotiable instrument can be mailed or held 
30 at the agent location 125 for pickup. Other embodiments could have multiple payees 130 
where the negotiable instruments are optionally held at an agent location 125 for pickup. 

This process 600 begins to notably differ from the embodiment of FIG. 5 A 
in step 620 where a single identifier for a single payee 130 is entered. Continuing on to 
step 628, the payor 1 10 enters the transfer amount for the payee 130. The payment 
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enabler 170 in step 536 gathers the money from the default handler 160 previously 
indicated by the payor 110. In step 640 the type of payout is chosen from: a payout to a 
stored value fund, an external payout that is sent to the payee location, or an external 
payout that is made available for pickup. The latter two options are described in relation 
to FIG. 5 A. 

Where the external payout for pickup option is desired, processing 
continues to step 664 from step 640. Where an external payout is performed, the stored 
value fund used in step 536 can be a temporary fund that can be removed from the system 
after the payee 130 receives the money. In step 664, a message is made available to all 
agent locations 125 with a negotiable instrument printer 412 that indicates a payee name 
and an amount. When the payee 130 arrives at a chosen agent location 125, the agent can 
use the agent interface 180-4 to the payment enabler to verify the payee 130 is due 
payment. After verification of the identity, the negotiable instrument is printed for the 
payee 130 in step 668. 

With reference to FIG. 6B, a flow diagram of another embodiment of the 
process 670 for transferring money with the negotiable instrument where the payor 110 
uses an agent location 400 is shown. In this embodiment, the payor 1 10 remains external 
to the system 100 without the need for personally interfacing with the payment enabler 
170. The depicted portion of the process begins in step 674 where the payor 1 10 provides 
money at an agent location 125. The money could be in the form of cash, a credit card or 
a check. In step 678, the agent enters an identifier for the payee 130, such as an e-mail 
address. In step 682, the agent enters a money amount for that payee 130. The agent 
interface 180-4 is used to enter the identifier and amount. The remainder of the process 
670 is largely the same as the embodiment of FIG. 6A. 

Some embodiments may avoid step 536 where a possibly-temporary stored 
value fund is created for the payee if the payee doesn't already have one in the case of an 
external payout as determined in step 640. The amount would go directly to the handler 
that prints the negotiable instrument for pick-up or mailing. Other embodiments may 
load the amount into a stored value fund of the payor before transferring that amount to 
the stored value fund of the payee. 

Referring next to FIG. 7, a flow diagram of an embodiment of a process 
512 for configuring a user with an account with the online money transfer system 100 is 
shown. Where the payee 130 or payor 1 10 is not external to the system, an account with 
the payment enabler 170 is created. The depicted portion of the process 512 begins in 
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step 704 where the user 1 10, 130 enters an e-mail address as the unique identifier for the 
account. The user may want to enter any other e-mail addresses that may be used by 
counter parties to a transaction. Other embodiments could use any unique identifier for 
the user. 

5 Once an e-mail address is given to the payment enabler 170, it is verified. 

A message is sent to the e-mail address in step 708. A code is provided and an URL such 
that the user can click on the URL to load a page where the code is entered to verify the e- 
mail address. In this embodiment, the code is a randomly generated set of alphanumeric 
characters. Other embodiments could use any number of methods to verify the e-mail 
10 address. 

The user enters contact information in step 712. This contact information 
could include address, phone number, pager address, instant message address, wireless 
h phone address, contact e-mail address, etc. In step 716, the user enters handler interface 

D information. For example, the user might enter credit card information and bank transfer 

m 15 information. In step 720, the information is verified with the handler 160 to the extent 

f] possible for that handler 160. In step 724, the process 512 can loop back to step 716 for 

h j entering and verifying additional handlers. 

f In step 728, a default input handler 160 and a default output handler 160 

h can be chosen for transferring money into and out of the system 100. These handlers 160 

20 may be different. In step 732, the payment enabler 170 waits for verification at least one 
H of the e-mail addresses before activating the account for sending and receiving money 

with that e-mail address in step 736. 

With reference to FIG. 8, a flow diagram of an embodiment of a process 
536 for transferring money from the payor 1 10 to the payee 130 is shown. The process 
25 536 describes a transfer between a single payor 1 10 and a single payee 130, but a number 
of these processes 536 could be performed in parallel where there are a number of payees 
130. The depicted portion of the process begins in step 804 where the payee 130, payor 
110 and amount are determined for the money transfer. In step 812, it is determined if the 
stored value fund of the payor 1 10 has enough money to fund the transfer to the payee 
30 130. 

Where there is not sufficient funds in the stored value fund, processing 
continues to step 816 to load funds. In step 816, the default pay-in handler 160 is 
determined. The information used to transfer money from the handler 160 into the 
payment enabler 170 is retrieved from the user database 324 in step 818. The payor 110 
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may be given an opportunity to change the default pay-in handler 160 for this transaction 
or for all further transactions. Presuming there are no changes, the default handler 160 is 
interfaced in step 820 to transfer the money. If there is no stored value fund for the payee 
130, a temporary fund is created in step 824. A temporary stored value fund can be used 
5 for a single transfer, but the payee may want to make the temporary fund permanent by 
opening an account with the payment enabler 170. 

Regardless of whether new money is added or whether existing money is 
used, processing continues to step 828 from both step 812 and step 824. The money is 
attributed to the payees 130 stored value fund to the detriment of the payor's stored value 
10 fund in step 828. In other embodiments, the money is transferred directly from the 

payor's handler 160 to the stored value fund of the payee 130. In some embodiments, the 
payor can select a future time that payment is made such that the payment is configured 
now, but completed at the future time. 

Referring next to FIGS. 9 A and 9B, a flow diagram of an embodiment of a 
1 5 process 560 for moving money out of a stored value fund of a user is shown. This 

embodiment allows paying-out money in at least five different ways, namely, by: pick-up 
at an agent location 125, exchanging with some promotion, a credit to a debit or credit 
s card, a credit to a bank account, and mailing a negotiable instrument. The depicted 

□ portion of the process 560 begins in step 904 where the default pay-out handler 

20 information is retrieved for the payee 130. In step 908, a web page is presented that 

□ allows the payee 130 to select a different handler 160 or to change information for the 
H : handler 160. 

A user may have a number of currencies of money in their stored value 
fund. The user may select some or all of the different currencies for paying out. In many 

25 cases, the handler 160 only accepts money in a single currency or the user may simply 
wish to exchange money to another currency. In step 910, the currency is exchanged. 
The exchange rate database 332 is queried for the current rate that is applied by the 
payment conversion function 328. 

In step 912, processing branches in one of five directions depending on the 

30 type of handler the user has chosen. The first two directions are depicted on FIG. 9A and 
the remainder are depicted on FIG. 9B. One branch beginning in step 916 corresponds to 
the user visiting an agent location 125 to transfer out money with the assistance of the 
agent. In step 916, the user selects an agent location 125 that is convenient. The user 
visits the agent location 125 in step 924 to either use a kiosk interface 180-2 or use the 
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agent. In this embodiment, the user interfaces with the agent who uses the agent interface 
180-4 to the payment enabler 170. From the agent interface 180-4, the agent can transfer 
the money to any handler 160, can print a negotiable instrument or can provide cash to 
the user. The transfer is recorded by the payment enabler 170 in step 932. 

5 In another branch that begins in step 936, a promotion program is chosen 

as the handler 160-1. Either the promotion handler 160-1 or the exchange rate database 
332 can be queried in step 936 to determine the exchange rate for program credits or 
points. In step 940, the conversion rate is presented to the user for approval. Presuming 
the rate is approved, the promotion credits or points are purchased in step 944 by 

1 0 interfacing with the promotion handler 160-1. The payout of money to the promotion 
handler 160-1 is recorded in step 932. 

In yet another branch that begins in step 948 of FIG. 9B, a credit card or 
debit card is used to transfer out money from the system 100. In step 948, a credit 
message is formulated for the card bank. In some embodiments, the identity of the card 

1 5 holder may be further verified by entry of a PIN or other verification method. The card 
bank is contacted in step 952 for authorization of the credit. Authorization of the credit is 
performed in step 956. The payout is recorded with the payment enabler 170 in step 932. 

In the branch labeled "B," a bank transfer is used to payout money from 
the system 100. In step 960, an EFT message is formulated for the handler bank 160-4. 

20 The EFT message is sent to the handler bank 160-4 in step 964. Receipt of the EFT 

message is confirmed by the handler interface 308 in step 968 and the transfer is recorded 
in step 932. 

In the branch of FIG. 9B labeled "C " a negotiable instrument is printed 
and sent to the user. In step 972, the user enters the delivery address and a name to pay 

25 the negotiable instrument to. The user can send the negotiable instrument to herself or a 
third party. A delivery method for sending the negotiable instrument is chosen in step 
976. In step 980, the negotiable instrument is printed or otherwise produced and sent. 
The payout is recorded in the user database in step 932. 

With reference to FIG. 10, a flow diagram of an embodiment of a process 

30 1 000 for automating future transfers is shown that uses the online money transfer system 
100. In some circumstances, a user may want to automate the payout or payin of money 
from or to her stored value fund. There are two types of automated transfers, namely, 
threshold and fixed transfers. Threshold transfers aim to maintain a specified amount of 
money in the stored value fund such that money is either transferred in or transferred out 
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to maintain that specified amount. Fixed transfers pay-in or pay-out a fixed money 
amount according to specified frequency. 

The depicted portion of the process 1000 begins in step 1004 where the 
user selects a handler 160 for the automated transfer. In step 1008, the type of automated 
transfer is selected. For a threshold transfer, the user enters the threshold amount in step 
1012 as a trigger condition. For a fixed amount transfer, the user enters the amount of the 
transfer in step 1016. Once the type of transfer is chosen, the direction of the transfer is 
selected in step 1020 such that money is automatically added or removed from the stored 
value fund. 

A frequency for the automatic transfers is chosen in step 1024. For fixed 
transfers, the fixed amount is transferred at that frequency such that the period expiring is 
the trigger condition. For example, $50 could be transferred into the stored value fund 
weekly. For the threshold transfers, the transfer threshold is tested at the specified 
frequency. For example, once a day any balance in excess of $1,000 is transferred out of 
the stored value fund. In step 1032, a test is performed for the frequency period expiring. 
When the period expires, money may be transferred in or out of the stored value fund in 
step 1036. After any transfer, processing loops back to step 1032. 

Some embodiments could notify the user when an automated transfer 
occurs. Although the embodiment of FIG. 10 only describes a single automated transfer, 
other embodiments could allow multiple automated transfers having various types and 
transfer periods. Further, some embodiments could transfer amounts over/under the 
threshold amount whenever overage/underage occurs without waiting for the transfer 
period to expire. 

Referring next to FIGS. 1 1 A and 1 IB, a flow diagram of an embodiment 
of a process 1 100 for subscribing to automated transfers is shown. Under certain 
circumstances, a user may wish to pay for recurring charges or a future transfer with her 
stored value fund. If a vendor site accepts subscriptions, the user can configure payment 
in this way. In this embodiment, there are three different types of subscriptions, namely: 
a recurring and fixed amount is transferred, a fixed amount is transferred whenever 
requested and a variable amount is transferred when requested so long as it does not 
exceed a limit. Other embodiments could arrange other subscription transfers between a 
user and a vendor. 

The depicted portion of the process 1 100 begins in step 1 104 where the 
user is prompted by the vendor site to allow payout through the payment enabler 170. If 
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the user does not want to pay with her stored value fund as determined in step 1 108, the 
vendor site may provide other payment options in step 1112. Presuming the user wants to 
payout from the stored value fund in step 1 108, processing proceeds to step 556 where an 
account is opened for the user in step 512, if necessary. 
5 So long as an account is open for the user, processing continues from 

either step 556 or step 512 to step 1116 where the subscription type is selected by the 
vendor and presented to the user. In some embodiments, the user may be presented with 
a couple of subscription choices that can be selected. 

There are three branches from step 1 1 16 for the three transfer options, 
10 namely, a recurring and fixed transfer amount is selected in step 1 120, a fixed transfer 
y amount is transferred whenever requested by the vendor in step 1 128, or a capped, 

O variable, amount is transferred whenever requested in step 1 124. The fixed, on-demand, 

J payment in step 1 120 can have its period limited by the user such that only a number of 

UH payments is available in a period, such as once a month. The capped, variable, amount 

Qj 1 5 branch of step 1 124 could be further limited such that only a maximum amount is allowed 

for a period of time. 

y ; Once the vendor chooses a subscription type, it is presented to the user in 

O step 1 132. The user authorizes the automatic transfers in step 1 136. In step 1 140, the 

jy payment enabler waits for an automatic transfer. In this embodiment, the vendor initiates 

O 20 the transfer, however, some embodiments could have the payment enabler 170 contact the 

vendor at a defined frequency for fixed or variable payments. For example, a ten dollar 
fee could be paid every business day to the vendor without solicitation. 

Where an automatic transfer is requested by the vendor, that request is 
check by the payment enabler 170 in step 1 144 before fulfillment. The user can put 
25 frequency and/or amount limitations on transfers to the requesting vendor. If an attempt 
to violate the limit is detected, the vendor and/or the user is notified. The user may adjust 
the limits in view of the attempt to exceed the limit. 

An electronic notification is sent to the user of the transfer when accepted 
by the payment enabler 170. The user can specify whether these notifications are sent or 
30 under which circumstances they should be sent. For example, the notification could 

include vendor information, a description of the goods and an amount for transfer. For a 
period of time, the transfer is pending and can be canceled by the user. In step 1 152, the 
user can cancel the transfer, whereafter, the vendor site is notified in step 1156 and the 
subscription may be canceled or suspended by the vedor in step 1 160. If the transfer is 
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not canceled during pendency, the money is transferred to the stored value fund of the 
user in step 1 164. In some embodiments, the money is transferred directly to the handler 
160 pre-specified by the payee so as to skip-over the stored value fund of the user. 

A number of variations and modifications of the invention can also be 
used. For example, when sending a printed check to a payee a telegram or greeting card 
can be enclosed therewith. Additionally, an electronic greeting card sent to the payee 
could include a payment notification. The payment notification would include a link to 
the payment enabler such that the payee could easily retrieve the money from the system. 

While the principles of the invention have been described above in 
connection with specific apparatuses and methods, it is to be clearly understood that this 
description is made only by way of example and not as limitation on the scope of the 
invention. 
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